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Abstract 


The demands of developing modern, highly dynamic applications 
have led to an increasing interest in dynamic programming languages 
and mechanisms. Not only must applications evolve over time, but 
the object models themselves may need to be adapted to the re- 
quirements of different run-time contexts. Class-based models and 
prototype-based models, for example, may need to co-exist to meet the 
demands of dynamically evolving applications. Multi-dimensional dis- 
patch, fine-grained and dynamic software composition, and run-time 
evolution of behaviour are further examples of diverse mechanisms 
which may need to co-exist in a dynamically evolving run-time envi- 
ronment. How can we model the semantics of these highly dynamic 
features, yet still offer some reasonable safety guarantees? 

To this end we present an original calculus in which objects can 
adapt their behaviour at run-time. Both objects and environments 
are represented by first-class mappings between variables and values. 
Message sends are dynamically resolved to method calls. Variables 
may be dynamically bound, making it possible to model a variety 
of dynamic mechanisms within the same calculus. Despite the highly 
dynamic nature of the calculus, safety properties are assured by a type 
assignment system. 
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1 Introduction 


There has been a recent re-emergence of interest in dynamic programming 
languages [21] and the development of more dynamic features for main- 
stream languages such as Java. Increasing numbers of applications require 
the ability for configurations and even system behaviour to evolve at run- 
time. Furthermore, behaviour may be context-dependent, and may need 
to adapt to the run-time platform, the end user, service availability, or 
any number of environmental attributes. To support these highly dynamic 
applications, programming languages need to support a range of different 
object models, paradigms and language features. 

Multi-dimensional dispatch is one example of a such a feature — instead 
of dispatching purely on the receiver of a message, the behavior of an object 
might depend on the sender, or even on contextual information such as the 
deployment platform, available services, desired quality of service, available 
versions of components, or even the time of day [14]. Another example is 
the use of fine-grained components, such as traits, to statically or even dy- 
namically extend the behaviour of classes [7]. These and other mechanisms 
entail the need for specialized lookup mechanisms to adapt the behaviour 
of objects, even at run-time [24]. 

It is unclear what the impact of such dynamic features may be on the 
semantics of programming languages, and on the ability to reason about 
type safety in the face of dynamic changes. To this end we have developed 
a stateful calculus of evolving objects in which: 


e Object behaviour is context-dependent — message-dispatching takes con- 
text into account. 


e Objects may change their behaviour at run-time — message-lookup may 
be dynamically updated. 


e Dynamic changes are type-safe — message-not-understood errors are 
avoided. 


Particular innovations of the calculus include: 


e The use of first-class environments to model both the object states 
and the environments in which expressions are evaluated. 


e The possibility of binding dynamically variables by freezing expres- 
sions containing free variables and defrosting them in a runtime envi- 
ronment providing binders for them. 
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e Distinguishing message sends from method calls to support object- 
specific (context-dependent) method lookup. 


e A novel type system which — in addition to safety properties — assures 
that variables in an evolving environment are bound to values of fixed 


types. 


The paper is organized as follows. In Section 2 we motivate the calculus 
through an example. The syntax and the operational semantics of the lan- 
guage are introduced in Sections 3.1 and 3.2. In particular, Section 3.1 
introduces the lambda-calculus of environments that is the core functional 
part of our calculus and in Section 3.2 we add imperative extensible objects 
in which message send is not identified with method call. In Section 4 we 
present an overview of the type system with the relevant results. In Section 
5 we place our work in context and contrast it to other approaches. We 
conclude in Section 6 with some remarks on current and future work. The 
Appendix contains proofs. 


2 Motivating Example 


In this section we introduce the essential constructs of our calculus with the 
help of a motivating example. 

Suppose we want to model a Call Center that answers calls for different 
clients. When a client calls the Call Center from a known number, then the 
caller should be directly connected to a dedicated service for that client, for 
example, to play back recorded calls, or to be connected to the representative 
for that client. If someone calls from an unknown number, then a default 
service should be triggered, such as connecting the caller to the switchboard. 

In a conventional object-oriented approach, messages are dispatched 
purely on the basis of the receiver. Each object has its own methods for 
responding to different messages. In the Call Center example, the method 
for responding to a message depends not only on the receiver, but also 
on the sender. In general, arbitrary contextual information may influence 
the desired behaviour. For example, depending on the time of day, or the 
occurrence of a holiday, the Call Center’s behaviour might change. To 
further complicate matters, the behaviour of the Call Center will need to 
be adapted dynamically as clients come and go. 

The operational semantics of object-oriented languages and systems 
have been extensively studied in the framework of so-called object calculi. 
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Most of these calculi extend the lambda calculus with first-class records 
used to model objects and classes. Method and field lookup for objects are 
modeled by looking up fields of records representing classes and objects, 
possibly following an inheritance chain. The seminal work is by Abadi and 
Cardelli [1], who developed a series of such object calculi to model various 
technical aspects such as inheritance, recursion and subtyping. 

Other well-known examples of object calculi based on extending the 
lambda calculus with records include the imperative approach of Flatt et 
al. [10] used to study the addition of mixins to Java-like languages, and 
the purely functional approach of Igarashi et al. in Featherweight Java [15], 
used to reason about the impact of adding generics to the type system of 
Java. Researchers more interested in aspects related to concurrency and 
distribution, on the other hand, have taken process calculi as a starting 
point [27]. 

All of these approaches follow an orthodox object-oriented regime in 
which messages are dispatched on the basis of the receiver. 

We propose to extend the conventional approach to object calculi to 
take context into account when dispatching messages. First, we propose 
to reify contextual information as first-class environments. Although first- 
class environments have been studied before to model explicit substitutions, 
they have not been used before to model context-dependent behaviour of 
objects (see also related work in Section 5). Message lookup can thus take 
place within a dynamically configured environment. In order to dynamically 
bind expressions to different environments, however, we need to be able to 
manipulate expressions containing free variables. We therefore propose a 
mechanism to freeze potentially open expressions and defrost them within 
a given environment. In order to maintain a fine degree of control over 
the desired semantics of method lookup, we introduce mechanisms that 
distinguish between message sending and method lookup. Finally, we ensure 
that these operations are type-safe. 

Our calculus extends a lambda-calculus with explicit substitution and 
models both execution environments and object fields as sequences of bind- 
ings between variables and values, 71;=Vj----%nj=V;,, denoted by the meta- 
variable FE. Objects are imperative, so each object is associated with an 
environment that represents its current state. 

We represent the Call Center by an object, v, and the request by sending 
the message m. Instead of being associated to a field of the object of name 
m, the method corresponding to m is dynamically looked up, with a lookup 
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function for the Call Center, that uses the message name, the information 
about the sender, and the identity of the sender. 

The lookup function needs to manipulate message names as values in 
order to bind them dynamically to the appropriate environment. We there- 
fore distinguish between two ways to bind the free names when evaluating 
an expression in an environment, depending on whether they need to be 
manipulated or not. 


e The first is the sandbox expression E; A, in which the free variables of 
the expression A must be statically bound to variables defined in the 
environment E. 


e The second is a conditional expression Eo(A)oB to handle the situa- 
tion where the free variables of A might not all be captured by E. If 
they are, the conditional reduces to EF; A as above, otherwise it reduces 
to the expression B (analogous to a try/catch block for exceptions). 


The conditional expression makes use of the construct (A). This freezes 
the expression A, turning it into a closed value even if A contains free 
variables. In particular, given a (free) message name m, (m) is a value, 
whereas m is not. A frozen expression can be evaluated (defrosted) only in 
an environment that provides bindings for all its free variables. In case all 
the free variables of A are defined in E, the expression Fo(A)oB reduces to 
E; A, thereby dynamically binding the free variables of A to the environment 
E. If E does not define all the free variables of A the evaluation of the 
expression Fo(A)oB reduces to B. 

Lookup functions can take into account not only the name of the mes- 
sage, but also additional contextual information, such as the identity of the 
sender. The sender is determined at run-time. In our calculus we provide 
both a user syntax and a run-time syntax for message sends. The user 
writes A m(B), to send message m to the object denoted by A with B as 
argument. At run-time the actual message send will be represented by the 
syntax E’*A m(B), where E provides contextual information concerning 
the message sender extracted from the execution environment. 

Going back to the Call Center example, in case the sender is a client, 
we can assume that the request arrives from an object whose contextual 
information contains a binding, client=N, identifying the sender. If the 
sender is not a client, no such binding will be present. 

We use the notation *z to dereference object identifiers, so if is the 
reference to the Call Center, then *: denotes the environment associated 
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with 1. Now we can encode the behaviour of the Call Center in response to 
a client request as follows: 


Eo(ccClient client (request) )o(«.; defResp) (1) 


where F is the environment of the caller, ccClient represents the behaviour 
of the Call Center when the request comes from a client, and defResp is the 
field of the Call Center containing a default behaviour for requests coming 
from non clients. Let us assume that ccClient is a closed expression. Since 
(request) is frozen, hence closed, the only free variable of 


ccClient client (request) (2) 


is client. If we let the binding for client in E be client=N, the expres- 
sion (1) reduces to evaluating (2) in the environment (sandbox) EF’ produc- 
ing: 

ccClient N (request). 


So the Call Center process (request) for the client N. If E does not have a 
binding for client, then the value of the field defResp of the Call Center, 
is returned. In Fig. 1 we partially define a Call Center object such that a 


lkp = dAw.As.Am.wo(ccClient client m)o(*s;defResp) 
defResp = As.Ap.“Not a client” 


request = An.As.Ap.f np 


where ccClient = An.Am.((*L)ome(Ax.As.Ap. “Service not available” )) n 


Figure 1: The Call Center object 


request, (request), from a client is processed by selecting the value of the 
field request, which uses a function f taking as input the client number 
and the parameter provided from the client. As in the Abadi and Cardelli 
calculus, [1], methods have as first parameter a reference to self. (In 
this example this reference is not used.) The default behaviour bound to 
defResp, takes as input the parameter and returns the string “Not a client” 
In case the request comes from a client but it is not one of the defined 
requests the string “Service not available” is returned. The Call Center may 
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evolve to handle new requests (without changing the lookup function), or 
to change the policy of method selection, in which case the lookup function 
may change. 


3 Syntax and Operational Semantics 


The functional core of our calculus is a Call-By-Value lambda-calculus ma- 
nipulating environments (sets of bindings between names and values). We 
first introduce in Section 3.1 syntax and operational semantics of the stat- 
ically scoped section of the calculus which is a standard lambda-calculus 
with explicit substitutions. We then introduce the constructs related to 
freezing /defrosting expressions. In Section 3.2 we add to the calculus im- 
perative objects. 


3.1 First-Class Environments 


The syntax and operational semantics for the calculus are given in Fig. 2. 
The expressions of the calculus, A, B, ..., in addition to basic values, bv, 
which model integers, floats etc., and functions \x.A, include bindings, that 
are associations between names and expressions built from the empty en- 
vironment, (), or a binding, x=A using extension, A-B. The binding z=A 
defines x. Extension A-B models environment evolution: the binding r=B’ 
in B overrides a binding for x in A. This is expressed by the congruence on 
environments, =. 

Free variables are defined in the standard way. (The free variables of 
a binding «=A are the free variables of A.) 

The sandbox expression A; B evaluates B within the environment de- 
fined by A. Note that this implies that all the free variables of B must be 
defined in A, or the evaluation will lead to an error. The expression x is the 
lookup of x in the environment. Therefore, ();x is an erroneous term since 
x is not bound in the environment (). 

The operational semantics of this fragment of calculus is given by the 
relation between expressions, A — B, which is defined by giving the com- 
putational steps, —>,, and the reduction contexts that determine where they 
may happen. There are two kinds of computational steps: the first is the 
evaluation of an application, (Av.A) V which reduces to evaluate A in the 
environment in which x is bound to the value V. The second is evaluation 
of an expression within an environment. This pushes the environment into 
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Expressions A,B::=bv|Az.A|()|a=A|AB|AB|A;Bl a 
Values E,F::=()|c=V| EF U,V := E | bv | Azv.A 
Reduction Contexts C::=[]|z=C|C-A|V-C|CA|VC|C;A 
Congruence of environments 
E (c=U)-(x=V) 2=V. 
E (x=U)-(y=V) (y=V)-(a=U) ifaA#y 
(E-E')-F = E-(E'-F) 
Reductions: application, and nested reductions 
(Az.A)V —, (a=V);A if Fv(Arv.A) = 90 (app) 
C[|A] — C[B if A, B (cont) 


Reductions: substitution 


QE 
E() 


Es() -r (eptS) 
E;bv —, bv (conS) 
E;(a=A) -—, w=(E;A) (bindS) 
E;r2.A >, dax.((E-c=a); A) if x € FV(E) (absS) 
E;(A-B) =, (E;A)-(B;B) (extS) 
E;(A B) —, (E;A) (E;B) (callS) 
E;(A;B) —-, (E;A);B (sbS) 
E;z -, V if E = E’(x=V)_ (varS) 


Figure 2: Lambda Calculus with Environments 


the expression, replacing variables by their bindings, according to the rule 
(varS). 

Example. Let E = (true=(Aw.(Ay.x))-false=(Ax.(Ay.y))). This environment 
provides definitions for the abstractions true and false. We evaluate the 
expression true 3 4 in this environment, assuming integers as basic values, 
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as follows (we skip some trivial reduction steps to aid readability): 


E;true34 — (E£;true) (£;3) (£;4) 
— (Az.(ry.x)) 34 
— 2£=3;(Ay.x) 4 
— (2=3; Ay.x) (x=3; 4) 
> (Ay.(z=3-y=y; 2)) 4 
— (Ay.3) 4 
> y=4;3 
> 3 


Note how an application is evaluated not by direct substitution of variables 
as in the classical lambda calculus, but by explicitly building an environment 
within which the body of the lambda is evaluated. 

The only non-obvious rules of Fig. 2 are (absS) and (sbS). In rule (absS) 
the variable x cannot be free in EF, otherwise it would be captured by the 
A-binding. (This can be always achieved by renaming the variable bound 
by A.) Moreover, the environment F is extended with the binding r=z, 
so that A can contain free references to x. (Remember that in a sandbox 
expression the environment should close the expression.) The rule (sbS) for 
substitution in a sandbox expression, A; B, says that the substitution only 
affects the environment A, since B must be closed by A. 

In Fig. 3 we introduce the additions to the syntax and operational 
semantics to include frozen expressions, (A), and their conditional execution. 
Frozen expressions are values, e.g., (x) is a value whereas x is not. The 
reduction contexts specify that for an expression A’oA”oB we first evaluate 
A’, and then A”. We expect that A’ evaluates to an environment E and 
A" to a frozen expression (A). In the reduction rules the set DV(E) is the 
set of variables defined by FE, that is defined by: Dv(()) = 0, DV(vw=V) = 
{x}, and DV(E-E’) = Dv(E) U DV(E’). If the free variables of A are all 
defined by E, then Fo(A)oB reduces to the sandbox expression EF; A, rule 
(defOK), otherwise it reduces to B, rule (defEXC). The rule for pushing 
the environment in a frozen expression does not do anything since a frozen 
expression does not contain free variables. 

Example. Consider the expression A to be (Az.(y=3)0z05) (y), where we 
again assume that we have integers as basic values. The evaluation of this 
expression is shown in Fig. 4. Note that the expression (Ay.A) 7 that is 


(Ay.(Az.(y=3)0z05) (y)) 7 
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Expressions --- | (A) | AoBoB’ Values --- | (A) 
Reduction Contexts --- | CoAoB | VoCoB 


Reductions: execution of frozen expressions 
Eo(A)joB —, E;A if FV(A) C DV(E) (defOK) 


Eo(A)oB —, B if FV(A) Z DV(E) (defEXC) 
Reductions: substitution 
E;(A) —, {A) (frS) 
E;(AoBoB') —, (E; A)o(E; B)o(E; B’) (defS) 


= 
{ 

XR 
I 


}; (y=3))o(z=(y); z 


Deb A ded 


Figure 4: Example of Reduction 


also evaluates to 3, since the y in (y) is not bound by the lambda that 
contains it. Variables in frozen expressions are like global variables that are 
dynamically bound by the environment in which they are defrosted, similar 
to the special variables of Common Lisp [25]. 


3.2 Imperative Objects 


In this section we add to the calculus imperative objects. The syntax and 
operational semantics of the new constructs are given in Fig. 5. 

Objects are created with the new(A) expression that takes an environ- 
ment, allocates its value in the store (heap) and returns a fresh reference u 
to it. Given an expression A evaluating to a reference 1, the dereferencing 
expression *A returns the value associated with v in the store. Note that 
references / are not part of the source language, but are needed in the ex- 
pression language since they are generated during reduction. In the object 
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Expressions --- | new(A) | *A|A=B| A m(B) 
Run-time expressions 1 | E~A m(B) | (x)” 
Values --- |e 


Reduction Contexts 
+++ |new(C) | *C |C-=A|e-=C|C m(A) | E m(C) | EC m(A) | E™ mC) 


Store (maps references to environment) o: {11 + E\,...,ln > En} 
Reductions 
new(E),g —, t,alLr E| u is fresh (new) 
L,0 >, a(t),o (deref) 
l=E,o >, t,0[t/ o(t)-E] (evolve) 
uemV),0 >, (\um(V),o (addSr 
E™ m(V),o >, (Ab(b)2" 1 V) (V! Et (m)),o (send) 
where b is fresh and o(t) = F.(cta=E").(lkp=V’) 
Reductions: substitution 
E;(z)",o =, [V]¥,o if E = E'.(a=V) (varRTS) 
E;new(A),o -—, new(E;A),o (newS) 
Est,0 >, t,0 (objS) 
E;*xA,o —, *(E;A),o (derefS) 
E;(A-=B),o0 -, (E;A)-=(E;B),¢ (evolS) 
E;(Am(B)),o0 -, (E;A) m(E;B),o (sendS) 
E; (FCA m(B)),0 -, (E;F)°(E; A) m(E; B),o (sendRTS) 


Figure 5: Adding Objects 


evolution expression, A-=B, the environment associated with the reference 
contained in the environment which is the value of A is extended with the 
environment which is the value of B. In a message send, A m(B), the mes- 
sage m, with parameter the value of B, is sent to the object referenced by 
the value of A. In the expression E’“A m(B) the environment F contains 
the information about the sender of the message, to be determined at run- 
time. As we can see from the syntax, FE is not part of the source language. 
In fact, EF is generated by the reduction rules to keep into account the con- 
text information on the sender of a message. The run-time expression («)” 
stands for a variable that will be bound to a method body in which F will 
be added as sender to message sends. 

To take into account the imperative nature of the language, the con- 
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figurations that are reduced are pairs of the form (expression, store), where 
the store is a mapping from references to environment values. We assume 
that the store is added to the configurations of the operational semantics 
rules of Figs. 2 and 3 and that these rules do not modify or use the store. 

In rule (new) a fresh reference v is associated in the store to the envi- 
ronment value FE, and ¢ with the modified store are returned. Dereferencing 
returns the environment associated in the store with the reference 1, rule 
(deref). Object evolution, rule (evolve), extends the environment associated 
with the reference 4 with the environment EF. The reference is returned and 
the store is updated. Rule (addSr) adds the empty environment as sender of 
the method calls which are at the top level, ¢.e., that do not appear inside 
the bodies of method calls. 

Rule (send) specifies the reduction for message send, and it is the heart 
of our reduction. We assume that objects that may receive (and send) 
messages have two special fields: 1kp bound to a lookup function, and ctx 
containing the context information for the current receiver. 

The lookup function specifies how to search for the method body in 
response to the message m. For instance, for delegation based inheritance we 
first search in the current object a field m and if it is not present we continue 
the search in the delegate object, that is referred from a field. Similarly 
for class based inheritance, where an object instance of a class does not 
contain its methods that are instead contained in the object, representing 
the metaclass of the class. When creating an instance object we add a lookup 
function that starts the search for the field m in the metaclass of the class of 
the object. The lookup function does not depend on the specific object but it 
assumes that the object contains a field referring to the object representing 
the metaclass. The object metaclass will have a lookup function, which 
behaves similarly to the delegation based lookup, starting the search for m 
in the current object, and then if not found it continues the search in the 
object representing the metaclass of its superclass. 

Regarding the context information we only specify that this field con- 
tains an environment. (This information may be used in the loookup func- 
tion.) So in rule (send): 


E™ m(V),o0 —r (Ab.(b)” « V) (V! Eu (m)),o 


where b is fresh and o(v) = F-ctx=E’-1kp=V’, message m is sent to the ob- 
ject referenced by « which must have a field 1kp bound to a lookup function, 
V’, and a field ctx containing E’, the context information for the current 
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receiver. Let V” be the result of the evaluation of (V’ Eu (m)), that is 
application of the lookup function V’ to the information about the context 
of the sender contained in E, the receiver object +, and a frozen expression 
containing the name of the message to be sent; V” is the method that must 
be evaluated (in response to the message). As in the Abadi-Cardelli object 
calculus [1], a method is a function taking as first argument the receiver ob- 
ject and then the parameter. We model methods with just one parameter, 
however since parameters may be environments this is not restrictive. The 
context information for the current receiver E’ becomes the decoration of 
the variable 6, and therefore will provide the sender information of all calls 
which occur in the method V” (see the rule (varRTS)). 

The rules for substitution are all straightforward except for (varRTS) in 
which (x) in the environment E’-(x=V) is substituted by [V]’, namely V 
where F is added as sender to the message send expressions inside V. The 
definition of [V]" by induction on V is given in Fig. 6. The only relevant 
clause is the last one, that adds F as the context information to the method 
call. Note that (x)" is generated at run time by rule (send), (it is not a 


[a=B)” = x=([B]P [Bc]* = = [BF -[c]* 
[B=cC]* = [B\P =[c]* [B;C])” = [BIF;(C}F 
w.BlP = daw[Bl’ [B ClF = Ble iol? 
[+B]* = +[B)* [(B)]* = ([Bl*) 
[new(B)|* = new((B]") [BoCoD]* = [B]fo[C]¥o[D]” 


Figure 6: Definition of [A]* 


user expression) as we can see from the following example. For example 
[AsAv.s m(v)]* = AsdAv.FCs m(v). 

Example. Let 0 = {1 + Fy,12 ++ E 2} where EF, is obtained by adding 
ctx = () to the Call Center object of Fig. 1 and E> is defined by 


lkp = Aw.dAs.\m.(*«s)omo(As.Ap.“No such method” ) 
ctx = (elient=N) 
call = Xs.Ap. l, request(p) 


Let 
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e V, be Aw.As.Am.wo(ccClient client m)o(*s;defResp) (the lookup func- 
tion of the Call Center of Fig. 1), 


e V2 be Aw.As.Am.(*s)ome(As.Ap.“No such method”) (the lookup func- 
tion of the client), and EF be client=N (the context of the client). 


The relevant steps in the evaluation of '2 call(V) with store o, are as 
follows: 


lg call(V),o yg call(V 
a lo V 
ee lo V 


b) 
b) 
b)F lg V 
b) 


,o by (addSr) 

(V2 () tg (call)),o by (send) 
((tg)0(call)o---),o 

(F9;call),o since call is defined in FE 


Wt Ra Naa SS 


b=As.dp.t, request(p));(b)” 12 V,o by (app) 
As.Ap. Ei, request(p)) t2 V,o by (varRTS) and Fig.6 
Ey, request(V),o 
b.(b)Y wu. V) (Vi E uy (request)),o by (send) 
b.(b)Y uy V) (Bo(ccClient client (request))o---),o 
Ab.(b)Y i V) (E;(ccClient client (request))), a 
since client is defined in EF 
—* (\b.(b)Y 4 V) (ccClient N (request)),o 
V) ((«t1)o(request)o---) N),o 
—* (Xbd.(b)Y «1 V) ((E1; request) N),o 
since request is defined in Fy 

(Ab.(b)Y u V) ((An.As.Ap.f np) N),o 
—* (\b.(b)Y 4 V+) (As.Ap.f N p),o 

(b=As.Ap.f N p);(b)9 «1 Vio by (app) 
(x) * (As.Ap.f N p) 1 V,o_ by (varRTS) and Fig. 6 
EN 


——_~ 


ee ee ee 


Reductions (*) and (x) add the context information on the sender to the 
message send expressions in the expression bound to b. Note that in (x) 
there is no message send so the expression is not changed. 

Assume instead that the answering policy of the Call Center is the 
standard delegation. That is, first see if there is a method bound to the 
field request, if not delegate the answer to an object Delegate, referred to 
by the field delegate. For this, the object representing the Call Center of 
of Fig. 1 must contain a field delegate whose value is the reference to its 
delegate object. The lookup function of the Call Center, that is the value 
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associated with 1kp field would be: 
La = Aw.As.Xm.(*s)ome(((*D); 1kp) w D m) (3) 
where 


e D is the expression denoting a reference to the delegate of the Call 
Center, that is D = *s; delegate, 


e w is the context information of the sender (F in the previous example), 


e sis the reference to the receiver, in this case the Call Center object, 
and 


e mis the frozen name of the message ((request)). 


If the environment xs, the Call Center object, contains a binding for the 
name contained in the frozen expression m, in this case request, then the 
associated value is returned. Otherwise, we assume that the delegate object 
(referred by D) has a field 1kp containing a lookup function and (*D);1kp 
evaluates to it. This lookup function is applied to w, D, and m. 
Note that delegation is realized in a transparent way, since even when the 
method body is found in the delegate object the context information E of 
the sender will still appear as sender of all calls inside the body. 

It is possible to combine the lookup function of Fig. 1 with delegation 
so that the Call Center will serve requests coming from clients as in Fig. 1, 
and otherwise behave as in (3). 

The new lookup function is: 


L. = Aw.As.Am.wo(ccClient client m)o(Lqw sm). 
Similarly one can easily write lookup functions which implement class-based 
and trait-based searches of method bodies. 
4 Type Assignment System 


4.1 Types 


In this section we introduce a type system for our calculus. As usual [23] 
(Subsection 8.1), the shapes of types are suggested by the shapes of val- 
ues. We have basic types for basic values, arrow types for A-abstractions, 
reference types for object references. 
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The standard typing of a binding « = V is 2”, where 7 is the type 
of V [23] (Subsection 11.8). Since we are interested in expressing that a 
variable should be bound only to values of a fixed type, also in absence 
of a binding, we allow binding types of the shape x, where + € {!,?} is 
the modality. The meaning of x" is that x is actually bound to a value 
of type w, while x” says that x can only be bound to a value of type w. 
We say that x is the subject and w is the predicate of z'¥. The type of 
an environment (environment type) is a set of binding types with different 
subjects. The empty environment is naturally typed by the empty set. Note 
that environment types are sets of binding types, while environments are 
sequences of bindings. 

A frozen expression requires its set of free variables to be bound with 
values of fixed types: for this reason we type a frozen expression with a pair 
(Cw) (frozen type), whose first component I is a set of type assumptions 
for variables and whose second component w is the type we can derive for 
the expression under the assumptions in I. 

To sum up, we introduce the five kinds of types, w=, ¢, shown in Fig. 7, 
where [I is an environment type which contains only binding types with ! 
annotations. 

For environment types, we allow recursive types in order to type circular 
object structures, and also to type the application of a method body stored 
in a given object to a reference to the object itself. As usual recursive 
types are considered modulo fold/unfold. Fig. 7, where + € {!,?}, defines 
environment types, 7,v. An environment type is well formed if all types 
occurring in it are well formed, it does not contain (modulo unfolding of 
recursive types) two binding types with the same subject. For example 
rv, y’%2 is well formed if 71,2 are well formed, while pt.2'*,2’” is not 
well formed. The domain of an environment type 7, notation dom(r), is 
{x | at? er}. 

With zt? we abbreviate gh ore xine n> 0. We use x!” to indicate 
that the annotation of all the variables is !, similarly for ?. Let x” be short 
for '”. 


4.2 Typing Judgements and Rules 


As usual with calculi which deal with references, the typing judgements 
depend on two environments: a store environment % which associates object 
references to types and a standard environment T which associates variables 
to types [23] (Section 13.4). Then we define 
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K Basic type 
ww Arrow type 
refT Reference type 
([,w) Frozen type 
T Environment type 
= ai¥ Binding type 
| 7,7 Sequence type 
| Type variable 
| pt.r Recursive type 


Figure 7: Kinds of Types and Environment Types 


Note that a not empty standard environment is an environment type in 
which all modalities are !. 
The typing judgement: 


S;TFA:w 


says that under the environments ©) and TI the expression A has type w. 
In the following we present and comment some significant rules. The rest 
of the rules can be found in Fig. 8. 

We first consider the rules concerning bindings and environment exten- 
sions. 


SPA See Be 
3 (Thind) T and 7’ compatible 
O;CF AB: 3-7’ 


STFA: wh 
Y;Tbka=A:al 


(Text) 


For typing a binding we require that the expression bound to x has type w 
in order to derive the binding type «'”. Note that the annotation could be 
either ! or ?. 

Two environment types 7 and 7’ are compatible if for x € dom(T) MN 
dom(r') we have that x has the same predicate in r and 7’ with possibly 
different annotations. For example x'”', y’¥? and x”! are compatible, while 
they are not compatible with x'”2, y?”2 if wy is not wo. 
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(Tempty) ——_—— (TBV) 


y;TFO:0 y;0TF bv: kk 
U;P-c?b+ A: STFA: d-w USTEB: 6 
(Tabs) }=§ —————_——_—_——— (Tapp) 
Y;PbFAr.A: yo S;TFAB:yW 
sv’ eT eer S:TFE:@ 
———— (Tvar) (TvarRT) 
YTPra:y Ob (2)® : 
SST bh Ass b:TED u;Db A: refr 
(Tnew) ——_—___——— _(Tref) ————————_ (Tderef) 
u;T- new(A) : refr Y;DP Fc: refr U;PF «A: 


SCF A:refr STE B:y += pt.mi¥,1kp'?, ctx!”,7’ 
p=reft yy ow" bd=aw-reft — (m’,y) > +t not in’ 


(Tmes) 
u;0F A m(B): wy" [r/t] 


Figure 8: Some Typing Rules 


The extension, T-7’, of the environment types T and 7’ is defined —if r and 
7’ are compatible — as the set-theoretic union of the two binding types, in 
case two bindings share the same subject (they must have the same predicate 
by definition of compatibility) we take as annotation the upper bound of 
the two annotations defined by: if — = t/ =?, then — Lj! =? else 7 Lt’ =!. 
That is in the resulting environment type all the fields that were defined in 
one of the environment types are defined. 
The environment extension is typed by the extension of the environment 
types. 

With rule (Tsub) that follows, to an environment type 7 we can add 
any binding with annotation ? for variables that are not already defined in 
a: 


S;TFA:¢7 ror 


(Tsub) 
Seb Ase 
where the subtyping relation, C, between environment types is the reflexive 
and transitive closure of: 
eld «xg dom’) 
(envAS) 


old ,a™ 
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0;0 + s:refr D 0;P Em: (m?,y) 
OT Pasar 00K m:(m*,v) 0,2 Aw (*s;d) m: 
0;0 F (xs)omoA w (*s;d) m:wW 


0;{w:@,s:reft}t Am.(xs)omoA w (*s;a) m: (m’,w) — w 
0;{w: am} As.Am.(*s)omoA w (*s;d) m:reft > (m®, wy — 
0:0 + Xw.As.Am.(*s)omoA w (*8:d) m:@ — refr > (m*,y) > b 


where ' 
D OTkw:a 0; xs:7 0;d77 -d: refr’ 


Die 0:0 Aw:refr’ > (m",v) + u 0; + *s;d: refr’ 
0;T + A w (*s;d) : (m”, a) ow 


0; + xs;d: refr’ 
D2 0;T F *(*s;a) : 7’ 
0TH A:w— refr’ > (m*,p) ou 


A = (*(*s;d));lkp, d—=delegate, _[T—w:a,s:refrt,m: (m®,y), 
r=atet” yy, 7 = tlkp?,vy, ¢=mw—reft > (m’,y) > v. 


Figure 9: A Typing of the Lookup Function Lg 


In the rule for sandbox 
SPF A:7 Us{a'?|e'® er} b Bi 
S;PEA;B: wy 

we require that A is an environment type, and that B be typable from the 
environment containing only the variables that in the type for A have the 
annotation !, which are, from rule (Tbind), (Text) and (Tsub), the variables 
defined in A (with rule (Tsub) we can only add variables with annotation 
?). That is, the free variable of B must be defined in A. 


The rules for frozen expressions and their conditional execution are as 
follows. 


(Tsandbox) 


81 


MP PAte Ble Bao) 
0;TF A: »;CF Bl: dom(r) D dom(T’) 


iT’ F (A) : (0,0) (Tfreeze) 7 and I’ compatible 


E:DE AoBoB! : a) 


For a frozen expression (A), the expression A has never been reduced, and 
for this reason we require that no object reference occur in A. This condition 
is forced by the assumption that the store environment for typing A is empty. 
Instead the standard environment for typing A is packed with the type of 
A to build the frozen type of (A). 

In the rule for conditional execution of a frozen expression B we require 
that the variables free in the frozen component which is the value of B are 
subjects of binding types in 7, the type of A. These variables can be typed 
either with annotation ! if they are defined in A or with annotation ? if 
they have been introduced by the rule (Tsub). Moreover, the subjects of I’ 
must have the same types possibly with a different annotation in 7. This is 
assured by the conditions dom(r) D> dom(I’) and enforcing that 7 and I” 
must be compatible. We do not require (as in the rule for sandbox) that 
the free variable of the frozen component which is the value of B must be 
defined in A. 

In order to type object evolution, the expression A must reduce to 
an object reference v. Moreover the object stored at 4 must have a type 
compatible with the type of B. 


S;Tb A:refr };T+ B:r' + and 7’ compatible 
»;PF A=B: ref(r-7’) 
The type of the conclusion is the type of the reference . after the object 
evolution. Remember that, in our operational semantics, a binding in B 
overrides a field with the same name in A. For instance, we may change 
lookup function dynamically. 


The most complex rule, as for the operational semantics, is the rule for 
message send: 


MPR Asrete. BPE Big SP Ee oe 
T= pt.ml¥ ,1kp'?, ctx'”, 7! yw =reft > y! > yy” 
d=aw-reft > (m’,y) — t not in y’ 
MCF ECA m(B) : dh" [r/t] 
In this rule we put recursive types to work. To justify the types involved 
in the rule we have to consider the operational semantics rule (send) and 


(Tdyn) 


(Tevol) 


(TmesRT) 
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the fact that types are preserved by reduction. Let A and B reduce to the 
values U and V, respectively. In order to apply rule (send) to E-U m(V), 
the expression U must be a reference zs to an object, refr. This object 
has a field ctx, whose type is an environment type with only ? modali- 
ties. This environment type (denoted @) holds the contextual object in- 
formation that may be used by lookup functions to discriminate on the 
sender of a message. Moreover, the object has a field 1kp containing the 
lookup function V’ for the object. In order to correctly type the expression 
(Ab.(b)” 1 V) (V! Ec (m)) obtained by reducing E™ m(V), the lookup 
function V’ must have a type ¢, — ¢2 — ¢3 — 4 where ¢; = @ is the 
type of E (the sender information), ¢2 is the type of v (the receiver), 3 
is the type of (m) (the frozen name of the message), and ¢4 is the type of 
the method body, which is a A-abstraction applicable first to v (the self) 
and then to V (the actual parameter). Therefore, if refr is the types of 1, 
then 7 must be a recursive type pt.--- where t is the type of self. Then 
og = reft since the type of the second parameter of the lookup function 
is the type of the receiver. Let 7’ be the type of V, the parameter of the 
method, and w” the type of the result of the method, we have that ¢4, the 
type of the method body is ¢4 = w = reft — y’ — w”. Note that since w” 
may contain free occurrences of t, then the type in the conclusion of the rule 
is w” where all occurrences of t have been replaced by 7: as usual we denote 
it by w"[7/t]. Finally the type ¢3 of (m) is a frozen type in which in the 
environment m has type w, and the expression has type w. Moreover, since 
we want that the the lookup function may use m in a conditional expression 
(to search its definition) in 1 we require that 7 contain m!” to enforce the 
fact that an m present in v should be type consistent with the body found 
by the lookup function. 

Note that we can correctly type a unique lookup function for different 
method types and sender types, since our type assignment system derives 
many types for the same untyped expressions. If we would consider a typed 
calculus instead we would be forced to consider polymorphic types. 

Figure 9 shows a typing for the lookup function Ly as defined in (3) of 
Section 3.2. We assume that t does not occur in @ and w. For the subderiva- 
tion D’ note that 7’ = 1kp®”,v! where ¢! = w > refr! — (m”,w) — w and 
v’ is the result of replacing t by 7’ in v. 
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4.3 Safety 


In order to state the properties enforced by of our type system we define the 
agreement between a store environment and a store [23] [Definition 13.5.1]. 


Definition 1 A store environment © agrees with a memory oa (notation 
Lk o) if: 


e o(t) = E impliest:7 € XS and ;0+ E:7 for some r, and 


eu: TED implies c(t) = E and Y;0+ E: 7 for some E. 


Reducing expressions modifies the store, and for this reason also the store 
environment needs to evolve. 


Definition 2 We say that a store environment X’ is an evolution of a store 
environment & ift:7T € X implies .: 7-7’ € X! for some tr’ compatible with 
Te 


The two results insuring that well-typed expressions do not get stuck are: 


Theorem 1 (Subject Reduction) Jf; A: w andXto and A,o > 
B,o’, then 0';T/ B: wy and’ + o’ for some evolution X! of X. 


Theorem 2 (Progress) If ©;0+ A: and St o and A is not a value, 
then there are unique B’,o' such that A,o — B,o’. 


Subject Reduction also assures that: 


e variables in an evolving environment are bound to values of fixed 
types; 


e the free variables in the body of a sandbox are always bound in the 
environment of the sandbox. 


5 Related Work 


Abadi et al. were the first to study explicit substitutions as a way to bridge 
the gap between formal models of languages and concrete implementations 
[2]. The symmetric Lisp supports environments as first class objects, since it 
does not distinguish between data and programs [16]. Nishizaki developed 
a calculus of first-class environments in order to study dynamic software 
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evolution [22]. This calculus is purely functional and does not model objects 
or message sends. 

The Piccola calculus [3] extended Milner’s z-calculus [18] with first- 
class environments as a means to study and model software composition 
mechanisms. The functional core of the Piccola calculus, called the form 
calculus [20], has been used to study type inference for component-based 
service provision. A variant of the form calculus has also been studied 
by Lumpe and Schneider as a meta-framework for modeling composition 
mechanisms [17]. The object calculus described in the present paper can 
be seen as the form calculus, extended with an explicit object store, object 
references, message sending. 

Harrison and Ossher introduced the notion of subject-oriented program- 
ming to acknowledge the fact that behaviour does not always depend only on 
the receiver of a message but also its sender [12]. Smith and Ungar demon- 
strated how subjectivity could be realized effectively, and how it solves nu- 
merous problems related to the context-dependent behaviour [26]. Gil and 
Lorenz proposed environmental acquisition in which objects acquire be- 
haviour from the current containers at runtime [11]. More recently, context- 
oriented programming has emerged as a way to support multi-dimensional 
dispatch in object-oriented languages, and thus to adapt behaviour to the 
run-time context [14]. In the same strand [19] considers contextual effects, 
i.e., the effects of the computational contexts in which expressions occur. 

It is well-known that code migration requires dynamic reconfiguration 
of security policies: an interesting proposal is [13]. More difficult is mod- 
elling exchange of open mobile code, 7.e., code which may contain free vari- 
ables to be bound by the receiver’s code [8]. Ancona, Fagorzi and Zucca 
provide a combination of static and dynamic checks which assures type 
safety for mobile open code [4]. 

Type annotations are used by Damiani and Giannini [9] to discriminate 
whether a given field is defined or undefined in an object. Anderson 
and Giannini [5] used “defined/maybe” annotations on types and recursive 
types in an object based calculus in which fields may be added to objects. 
Recursive types are used, in a limited way, to type an object’s “self” as 
well as functions returning functions. An inference algorithm has also been 
defined for this type system [6]. In both calculi message send is identified 
with method call [9] [5]. 
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6 Concluding Remarks 


We have presented a novel object calculus in which message sends are dy- 
namically looked up, taking into account contextual information such as the 
identity of the sender. Objects can evolve over time, as can the lookup func- 
tion itself. Method bodies may contain free variables which are dynamically 
bound when the method is invoked. First-class environments and “freezing” 
of expressions with free variables are the key mechanisms used to express 
dynamic binding. 

Despite the highly dynamic nature of the calculus, we have demon- 
strated how a type assignment system can provide the usual safety guaran- 
tees. 

We plan to design a type inference algorithm for the present system: 
this will be useful for experimenting with the present calculus without hav- 
ing the burden of checking typeability. 
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A Appendix 


A.1 Proof of Soundness 


The restriction of an environment I with respect to a set of variables X, 
notation I'{X, is defined as follows 


) fl = 9, 
TTX =< al¥, 0X ifae XandT =at¥, I" 
IX ifa é XandT = ait? I". 


The restriction of an environment © with respect to a set of object identifiers 
O, notation “JO, is defined similarly. 
By OID(A) we denote the set of object identifiers which occur in A and by 
FV(A) the set of term variables which occur free in A. 

Given an environment type 7, we denote by (7)! the maximal environ- 
ment type contained in 7 in which all binding types have the ! modality, i.e. 


we define: 
(n= ee ifr = 2'¥-7', 


(7)! ifr =a, 


The proofs of the following propositions by structural induction on 
expressions is straightforward. 


Proposition 1 Jf ©; - A: y, then dom(X) D oOID(A) and dom(T) D 
FU(A) and XfoID( A); A: and N;TSFV(A)F A: yp. 


Proposition 2 If A is a closed expression then either A is a value, or there 
is a unique context C such that A=C|R] for some redex R. 
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Due to the previous proposition given an expression A there is at most 


one rule applicable to A, so the reduction is deterministic. 


By looking at the typing rules we can easily prove the following stan- 


dard lemmas. 


Lemma 1 (Canonical Forms) 1. Jf; U:0@, then U = (). 


2. 


3. 


7. 


Ifu;TFU:k, then U = bv for some basic value bv. 


If; U : a',7, then U = E(2 = V) and 0; + E: 7 and 
o;TEV:w for some V. 


_IfO;ThU: 2,7, then either U = E-(2 =V) and 0;T+ E: 7 and 


U;TEV: wa for some E,V, orx ¢ DUU) and d;TEU:r. 


.IfUsTEU:¢—3 4%, then U = dz.A and D;T-2? + A: w for some 


Ax.A. 


fx; U : refr, then U =t andi: 7 € XS with +’ Cr for some 
/ 
is 


Ifo;TEU: (",wv), then U = (A) and d;I’ + A: w for some A. 


Lemma 2 (Inversion) Let ©;[TF A: w. 


1. 


2. 


If A is (), then p = 27%. 


If A is a basic value, then w = k, for some basic type k. 


_ If A is x, then for some w! we have that x” €T and yy! Cv. 


_ If A is (x)®, then; + E: w and c¥ €T, for some environment 


type w@ which only contains ? modalities and some y’ such that yy Cw. 


. If A is (B), then wy = (I",v’) and %;1’ + B: w! for some I’, y’. 


_ If A is c=B, then = xt" ,2°”, and S;:TE B: w! for some w’,x’¥. 


If A is \x.B, then b =! > 6 and d;T-x" + B: é for some wy’, ¢. 


If A is B-C, then = 7-7’ and U;Tt B: 7 and&d;P EC: 7’ for 
some compatible 7,7’. 


If A is B;C, then S;T + B: 7 and &;(r)'+ C: w for some r. 
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10. If A is BoCoC’, then ©; + B: 7, and ¥;T FC: (I",w), and 
u;0E C’: w, and dom(r) D dom(I”), for some compatible 7,1” . 


11. If Ais BC, thnd;TLB:y' > andd;TEC: Ww! and oC y for 
some o, y’. 


12. If A ist, then =reft andi: 7’ € Dd for some r' Cr. 


18. If Ais xB, then %;T + B: refw. 
1j. If A is new(B), then w= refr and };T+ B:7 for some r. 


15. If A is B-=C, then w = ref(r-7') and =; + B: refr and ¥; T+ 
C:7' for some compatible 7,7’. 


16. If Ais B m(C), then yp = w"[r/t] and U;T+ B: refr andd;TEC: 
wv! and tr = pt.mi, Ukp'?, cta’?, 7! and ¢! = reft > W! — wW" and 
¢=aw-—reft — (m*,¢') > ¢’ for some ¢, ¢',u,w",@ such that w 
is an environment type which only contains ? modalities and t does 
not occur in ¢’. 


17. If A is ECB m(C), then wW = w"[7/t] and U;T + B: refr and 
Y;TE OC: andd;T 4 E: @ andr = pt.mi®, tkp'?, cta’'”, 7! and 
df = reft — W > wl" and ¢ = @ — reft > (m*,¢') — ¢! for 
some ¢,¢',u"',w",@ such that w is an environment type which only 
contains ? modalities and t does not occur in wy’. 


Lemma 3 (Weakening) /f ©; + A: 7, andI’ DT, then ;I”+ A: y. 


Lemma4 17. /f5;T A: wy, and A=C[R], then };T + R: wy for 
some y’. 


2. If U:0 + C[R] : © where UP + R: y', ond O;0 + A: ow, then 
SDE CA]: wy. 


Proof: By induction on evaluation contexts. 
Given an environment type 7, and a set of variables X, we denote by 
7\X the environment type obtained from 7 by removing the types for the 
variables in X. _ _ 
If r}X = at¥ we define 7%) = g!¥, 


Lemma 5 1. Jf; + E:7, and x € DV(E), then al? Er and ;T+ 
E: (r\{a})-2'¥. 
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2. IfS;0F E: 7, and x ¢ DUE), then gil ET and BE e er \ ial, 
& If; E:7, then 4; E: 7h DVE)) | 


Proof: By induction on E£ using Lemma 1(3) and (4). 
Lemma 6 /f ©;TV:~%, andd;TL F: a, then d;TH [VIF : wy. 


Proof: By induction on V by noting that the only difference between 
the typing rules (Tmes) and (TmesRT) is the addition of the typing of the 
context F’ in the premise of the rule. 


Proof of Subject Reduction 


If=;Tb A: and Xt o and Ajo > B,o’, then 0';TtE BB: andd’t o’ 
for some evolution X! of &. 

Proof: Let first consider A,o —, B,o’. The proof is by cases on the 
operational semantics rule used. We do not mention the store when it is 
unmodified. 


e Rule (app). In this case A is U V and B is r=V; A’ where U = Ax.A’ 
and \x.A’ is closed. Since ©; A: Ww by Lemma 2(11) we have that 


Yreuses go (4) 
ETEVi¢ (5) 


for some ¢’ such that ¢/ EC wy. From (4) we get ©;0+ Av.A’: d > ¢! 
by Proposition 1. Therefore from Lemma 2(7) we derive that 


Sg? PA! og! (6) 
Applying rule (Tbind) to (5) we obtain: 
YP e=V :a?. (7) 
Therefore from (7), (6), and rule (Tsandbox) we have that 
SPE eeVeA ee’. 


Applying rule (Tsub) we derive ©; 2=V; A’: w. 
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e Rule (new). In this case A is new(F) and B is u and o’ is oft + FE, 
where v is fresh. From Lemma 2(14) we get w = refr and ©;T 
E : 7 for some T. We can take ©! = 1, : 7 and conclude using rule 
(Tref) and the definition of agreement between store environments and 
memory. 


e Rule (deref). In this case A is x. and B is o(v). From Lemma 2(13) 
we get ;C + 2: refw. By Lemma 2(12).:7 € X with 7 C y, 
which implies ©;[ - o(v) : w by definition of agreement between store 
environments and memory, possibly using rule (Tsub). 


e Rule (evolve). In this case A is -= E and B isu and o! = aft 
o(t)-E]. From Lemma 2(15) we get w = ref(r-7’) and ©; bv: refr 
and ©; + E: 7’ for some compatible 7,7’. We take 


Ge) — if = L, 


y’(v) otherwise. 


By rule (Tref) we get ©’; vc: ref(r-7’). Clearly ©’ is an evolution 
of % and Xt a implies U’ o’. 


e Rule (addSr). This case follows easily from Lemma 2(17) and rule 
(TmesRT). 


e Rule (send). In this case Ais E™ m(V), a(t) = F:(ctx=E’)-(1kp=V’) 
and B is (\b.(b)” « V) (V! Eu (m)). From Lemma 2(17) we get 
y=" (r/t] and 0; ke: refr and ©;TEV: #' and U;TFE:@ 
and + = pt.mi*1kp'?, ctx!”,7/ and d/ = reft > uw! > w" and 
¢=a-—reft — (m*,¢') > ¢’ for some ¢, ¢', 7’, w", @ such that w 
is an environment type which only contains ? modalities and t does 
not occur in w’. By Lemma 1(6) and the agreement between © and 
o we get ;0 + V’: ¢. This implies 5; + V’ Fe (m) : ¢/[7/t] by 
rules (Tfreeze) and (Tapp). We can also derive ©;T + Ab.(b)! io V : 
¢'[r/t] — w"[r/t], and so we conclude ©; + B: w"[r/t] using rule 
(Tapp). 

e Rule (defOK). In this case A is Fo(A’)oB’ and B is E; A’ and FV(A’) C 
DV(F). Since ©; A: w we have by Lemmas 2(10) and 1(7) that 
oC B:7 and Y;T F(A’): (’,y) and dom(r) D dom(I”) for some 
compatible 7,I’. We get dom(r7 |DV(E)) D> dom(I’ | Fv(A’)) which 
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implies 7“:>V(®)) 35 [’trv(A’). From Lemma 5(3) we derive ©;T + 
E : 7(:DV(2)). From Lemma 2(5) we derive 5;I’ + A’ : w and by 
Proposition 1 0; I’}FV(A’) FA’ : a, which implies 5; 7(/PV(2) | A’ 
w by Lemma 3. We conclude ©;[ + EF; A’: w using rule (Tsandbox). 


Rule (defEXC). In this case A is Fo(A’)oB’ and B is B’. This case is 
easy by Lemma 2(10). 


Rule (eptS). Let A be F;() and B = (). Since ©; F A: w we have 
by Lemma 2(9) that 5; + E: 7 and 5;(r)' + (): w for some 7. By 
Lemma 2(1) 5;(7)' + () : w implies ~ = x??. Applying rules (Tempty) 
and (Tsub) we get YU; (): 2”. 


Rule (conS). In this case A is E;bv and B is bv. Since ©;[F A: ~ 
we have by Lemma 2(9) that ©; + E: 7 and ¥;(r)! + bv : w for 
some T. From Lemma 2(2) we get w = kK, so we conclude applying 
rule (TBV). 


Rule (bindS). In this case A is E;2=A’ and B is x=(E; A’). Since 
o;r + A: w we have by Lemma 2(9) 5; + E: 7 and 5;(r)! + 
=A! : y) for some r. By Lemma 2(6) we have » = 27,21” and 
5; (7)! + A’: wy’, and so from rule (Tsandbox) we get 5; + E; A’: 
for some 2’, ~/. Applying rules (Tbind), (Tsub) we conclude 


oP + 2=(E; A’): o. 


Rule (absS). In this case A is EF; \x.A’ and B is Ax.(E-2=«); A’ where 
x ¢ FV(E). Since ©;[T + A: w we have by Lemma 2(9) that ©; + 
E:7 and 5;(r)'+ Az.A’: w for some r. From 5; (7)! + Aw.A’: w and 
Lemma 2(7) we have that 7 =’ — y" for some w” and 

yo; (r))-a¥” b Als ob". (8) 
From Proposition 1 and x ¢ FV(E) we have that ©;T[{r} + EB: 7, 
and from Lemma 3 ©; (T Na})-av" + &:7. From D2" F g=2: xe 
Lemma 3, and (Fia})-0¥ ») x’, applying rule (Text) we derive 


SPY + Eevee: re’ (9) 


From (9) and (8) by (Tsandbox) we get ©; (If{x})-a + (E-a=a); A’: 
w’. Finally by (Tabs) and Lemma 3 we conclude ©; + \wx.(E-2=2); A’: 
i 
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e Rule (frS). In this case A is EF; (A’) and B is (A’). Since H;TF A: wb 
we have by Lemma 2(9) that ©; E: 7 and 5; (r)' + (A’) : w for 
some 7. From Lemma 2(5) we derive w = (I’,~’) and ©; I’ + A’: yw’ 
for some y’,I’. We conclude ©;TF (A’) : w using rule (Tfreeze). 


e Rule (extS). In this case A is FE; Aj-Ag and B is (FE; A1)-(E; Ag). 
Since ©; + A: w we have by Lemma 2(9) that ©; + E : 7 and 
5; (7)! + Ay-Ao : w for some Tr. From Lemma 2(8) we derive that 
D3 (7) b Ay: 7%, i= 1,2 and w = 74-72 for some 71,72. Applying rule 
(Tsandbox) twice we have ©;[ + EF; A; : 7% for i = 1,2. Therefore, 
from rule (Text) we get 


uo; DF (B; A1)-(£; Ae): w. 


e Rule (callS). In this case A is E;(A’ B’) and B is (E; A’) (E; B’). 
Lemma 2(9) implies ©; + E : 7 and 5;(r)' + A’ B’: w for some r. By 
Lemma 2(11) we get 5;(7)' + A’: py! — w” and ;(r)' + B’: yy’ and 
w” Cw for some a’, 7". By rule (Tsandbox) ©; + E; A’: yf = y" 
and =; + E; B’: ~. We conclude using rules (Tapp) and (Tsub). 


e Rule (sbS). In this case A is FE; (A’; B’) and B is (£; A’); B’. Since 
»;P + A: a we have by Lemma 2(9) that ©; E:7 and ¥;(r)'+ 
A’; B' : w for some 7. Again by Lemma 2(9) we get ©;(7)! + A’: 7’ 
and 5; (r’)' B’: w for some 7’. Applying rule (Tsandbox) we derive 
first ©; £; A’: 7’ and then U;T' + (E£; A’); B’: vy. 


e Rule (defS). Here A is EL; A’oB,oBzy and B is (E; A’)o(E; By)o(E; Bo). 
Since ©; + A: w we have by Lemma 2(9) that ©; + E : 7 and 
5; (7)! - A’oByoBy : y for some tr. From Lemma 2(10) we derive 
that 0; (7)! + A’: 7! and 5;(7)! + By: (I’,w) and E;(7)' + By : 
and dom(r’) D dom(I’) for some compatible 7,I’. Applying rule 
(Tsandbox) we have ©; + E; A’: 7’ and ©;0 + E; By : (I’,w) and 
u;C EF; By: wv. From rule (Tdyn) we get 


0; Tb (£; A’)o(E; By)o(E; Bg) : v. 
e Rule (varS). In this case A is E;x and EF = E’.(x = V) and B is V. 
Since };I. + A: ~ we have by Lemma 2(9) that ©; + E : 7 and 


¥;(r)'t a: p for some r. By Lemma 2(8) 7 = 7/-v and 5; + E’: 7! 
and ©; t a =V:v for some 7’,v. By Lemma 2(6) we get v = a” 
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and ©;T KV: w’. From r = 7-2” and ¥;(r)! k x : w we conclude 
wy’ =w by Lemma 2(3). 


Rule (varRTS). In this case A is E;(x)* and E = E’-(x = V) and B 
is [V]”. Since 5; + A: # we have by Lemma 2(9) that 5; + E: 7 
and 5;(r)! - (x) : w for some r. By Lemma 2(8) 7 = 7/-v and 
SCF E’: 7’ and}; 2=V:v for some 7’,v. By Lemma 2(6) we 
get v = 2” and UST EV: yy. From tr = 7-2” and ©; (7)! a: o, 
by Lemma 2(4) we have that 7’ = 7, and =; + F: w. Therefore, 
4; V: y, and from Lemma 6 we derive that ©;T + [V]" : w. 


Rule (newS). Here A is E;new(A’) and B is new(E; A’). Lemma 2(9) 
implies ©;T + E : 7 and ¥;(r)' + new(A’) : w for some 7. By 
Lemma 2(14) we get = refr’ and 5; (r)'+ A’: 7’ for some 7’. By 
rule (Tsandbox) ©;[ + FE; A’: r’, so we conclude using rule (Tnew). 


Rule (objS). In this case A is E;. and B is v. Lemma 2(9) implies 
Oo; E:7 and ¥;(r)' +e: w for some r. By Proposition 1 5;0+ 
E;.:w and then ©; F E;7: Ww by Lemma 3. 


Rule (derefS). In this case A is E;*A’ and B is x(E; A’). Lemma 2(9) 
implies 5; + E: 7 and 5;(r)! + *A’: w for some r. By Lemma 2(13) 
we get ;(7)' A’: refy. By rule (Tsandbox) ©; + E; A’: refy, so 
we conclude using rule (Tderef). 


Rule (evolS). In this case A is F; (A’ = B’) and B is (FE; A’) =(E; B’). 
Lemma 2(9) implies ©; + E:7 and 5;(r)'+ A’.=B’ : a for some r. 
By Lemma 2(15) we get ~ = ref(r/-r") and 5;(r)! + A’: refr’ and 
5; (7)! - B’: 7” for some compatible r’,7”. By rule (Tsandbox) we 
get 0; + E; A’: refr’ and ©; + E;B': 7”, so we conclude using 
rule (Tevol). 


Rule (sendS). This case is similar and simpler than the following case. 
Rule (sendRTS). In this case A is E;(F’~A’ m(B’)) and B is 

(E; F)(E; A’) m(E; B’). Lemma 2(9) implies ©; + E : 7 and 
¥; (7)! k FCA’ m(B') : ~ for some r. By Lemma 2(17) we get 
w =" [v/t] and 5; (r)'+ A’: refv and 5; (r)'+ B’: yy and 5; (r)'+ 
F:o@ and v = pt.mi® ,1kp'®, ctx'7,v’ and ¢! = reft > yy! — w" 
and ¢ = w > reft > (m*,¢') — @! for some ¢,¢',W’,",@ such 
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that @ is an environment type which only contains ? modalities and 
t does not occur in 7’. By rule (Tsandbox) we get ©; + EF; A’: refv 
and ©; + E;B’:7y' and ©; + E; F : w, so we conclude using rule 
(TmesRT). 


If A,o — B,o’, then the only applicable rule is (cont). Therefore A is C[R], 
R —, A’, and B is C[A’]. By Lemma 4(1) we have that U;T R: vy’. 
By the previous proof we have that ©; + A’: ~’, and by Lemma 4(2) we 
conclude that ©;[TE C[A’]: wv. 


Proof of Progress 


IfX;0 A: andX to and A is not a value, then there are unique B’,o' 
such that A,o — B,o’. 

Proof: From Proposition 2 and ©}; + A: w, we have that there is a 
unique C such that A is C[R] for some redex R. 


Case: C =|]. The proof is by cases on redexes. For most of them we can 
reduce applying the corresponding rule, so we only consider the cases in 
which the rule has some side condition. 


e Case U V. By Lemma 2(11) ©;@t U V: # implies ¥;0- U: y+ @ 
and =;0+ V : y for some ¢, ~’. Therefore by Lemma 1(5) U = Az.A’ 
and ©; + Awv.A’ : wy’ — yw and so Ax.A’ is closed by Proposition 1. 
Rule (app) is applicable and B = (x = V); A’. 


e Case FoVoB’. By Lemma 2(10) ©;@ / EHoVoB’ : y implies ©; 9 + 
E:7 and 5;0+ V: (I’,~) and 4;@+ B’: ¢ for some ¢,7,T’. From 
Lemma 1(7) V = (A’). Therefore either rule (defOK) or rule (defEXC) 
is applicable. 


e Case EU m(V). By Lemma 2(17) ©;0 + E°U m(V) : w implies 
=;@+ U : refr for some T = pt.mi® 1kp'?, ctx'”,7’. Therefore by 
Lemma 1(6) U =. andv:7 € XY. From Yt o we get Y;0+ o(z): 
T, which implies o(4) = F-(ctx=E’)-(1kp=V’) for some F, E’,V’ by 
Lemma 1(3). (send) is applicable and B = (Ab.(b)” 1 V) (V! Eu (m)). 


e Case E; Axv.A’. We can always assume that x is not FV(E), by a- 
renaming. Therefore, rule (absS) is applicable. 
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e Case E;x. By Lemma 2(9) ©;@ + E;x2 : ~ implies ©;0 + BE: + 
and 5;(r)! E « : w. By Lemma 2(3) 2” € 7 for some wy’ C yw. 
Therefore 7 = 2,7! for some 7’. From Lemma. 1(3) we derive that 
E = E'.(x=V) for some E’ and V. So rule (varS) is applicable, and 
B=V. 


e Case E;(x)". The proof is similar to the case E; x. 


Case: C#[]. By Lemma 4(1) we have ©;0 + R: y’ for some y’. Then 
by previous case R —, A’ for some A’, and we conclude by applying rule 
(cont). 
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